第15章 XPのスケーリング

本書ではXPのおいてスケーリングさせる方法を要素別で解説する

人数

大きなチームが必要そうに感じても、まずは小さなチームで小さい問題を解決すること

小さなチームで解決が難しいなら、自立的な複数のチームで作業を分担する

人数を増やしたからといって解決するとは限らない

大きな問題に直面したときには、以下の3ステップを使う

問題を小さな問題に分割する

簡単な解決策を適用する

問題が残っていたら、複雑な解決策を適用する

投資

XPのソフトウェア開発を大規模にするのであれば、早い段階で財務面の協力者を見つけておくこと

組織の規模

XPを導入したいしたい場合、スキルの高いプロジェクトマネージャーが必要になる

新しいXPを無理やり導入しても、反感を買うことがあるので、組織に受け入れられるようなコミュニケーションが必要になる

壁に貼ったストーリーの説明などを共有したりプロジェクトマネージャーの負担が大きくなってくる

XPを取り入れてないチームで、プロジェクトマネージャーが四半期計画を作成するとき、週ごとにチームメンバーのやったことを聞いて回って、見積もりの精度をあげていった事例もある

期間

長期化のXPプロジェククトは自動テストやインクリメンタルな設計のおかげで、うまくいくことがおおい

頻繁に開始と停止を繰り返すプロジェクトは、プロジェクト維持をすることが難しい

問題の複雑さ

XPでは専門家同士で連携することが多い。連携をする専門家の情報を少しでも学ぶことができれば、チームの役に立てることが増えてくる。ゆくゆくは、ソフトウェア開発に恩恵をもたらすこともある

解決策の複雑さ

システムが成長すると、複雑になり解決策が不釣り合いになることがある。解決策から新たに問題を発生させないためにXPが存在する

継続的にデリバリーしながら、少しづつ複雑さを扱うための取り除いていく

計画づくりを見えるかすれば、時間がかかっていく箇所を把握できるため、適切な見積もりができるようになる

失敗の重大さ

命に関わるようなソフトウェアの場合は、XPだけでは不十分。安全性やセキュリティも考慮しないといけない

安全性やセキュリティの考慮が必要になるソフトウェアは、審査が必要になることがある。XPと共存していくためには、審査を日常業務に取り込む必要がある

審査は早めにこまめに行うことが重要

審査官と継続的な関係を気付けば、審査の成功率も高くなる